Make sure arenas don't allocate bigger than HUGE_PAGE #78058
Conversation
|
r? @lcnr (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
bugadani
changed the title
bugadani
changed the title
|
Hard to say, I lean on "not really". Shouldn't degrade perf, at least. |
|
this code is really hot, so it's better to be safe here @bors try @rust-timer queue |
|
Awaiting bors try build completion |
|
⌛ Trying commit 396561b with merge e270068a34bb00af7da331d9029c3b5ce2dad3d3... |
|
☀️ Try build successful - checks-actions, checks-azure |
|
Queued e270068a34bb00af7da331d9029c3b5ce2dad3d3 with parent ffeeb20, future comparison URL. |
|
Finished benchmarking try commit (e270068a34bb00af7da331d9029c3b5ce2dad3d3): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
|
Looks like no impact. |
|
well, then @bors r+ rollup |
|
📌 Commit 396561b has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions, checks-azure |
Right now, arenas allocate based on the size of the last chunk. It is possible for a
growcall to allocate a chunk that is not a multiple ofPAGE, and this size is doubled for each subsequent allocation. This means, instead ofHUGE_PAGE, the biggest page possible is actually unknown.This change fixes this, and also removes an unnecessary checked multiplication. It is still possible to allocate bigger than
HUGE_PAGEpages, but this will only happen as many times as absolutely necessary.